Give five contexts a verdict and re-read the trigger walk where it stopped reproducing - #220
Merged
iderex merged 2 commits intoAug 29, 2026
Conversation
The document is where issue #26 assembles the required set from, and a check name it gives no verdict to can be read as kept or as dropped with equal justice, so two readings produce two gates. A comment on that issue recorded that every declared name carried a verdict and evidenced it with a sweep whose only output was the six build entries. Re-run at 9208ceb, that sweep prints ten, and four of the new ones are a gap rather than the deliberate absence the build row covers: the three smoke entries and the smoke workflow's verify job. A fifth, release, the sweep cannot see at all, because the word matches inside the reason on another row and a fixed-string comparison cannot tell that from a verdict. All five read a tag or a published release, which a pull request has neither of, so they arrive on nothing a merge waits for. Requiring one would hold every merge open for a tick that is not coming, which is what required-context-nothing-reports refuses, so they are dropped permanently rather than until #26 and this document now says so in the same terms the table uses. What it prevents is the gate being assembled from a document that gives five of the names it is assembled from no answer, and the smoke jobs are the ones where reading it wrong costs most: they are the only check here that reads what an operator downloads rather than the source it was built from, so a reader who took them for droppable would drop the rule along with the tick. The paragraph separates the two. The means is prose in the existing parity document rather than a new file or a check, because what was missing is a verdict a person reads when assembling a required set by hand, and internal/contexts already holds the machine-readable half and already agrees with these five. Both pasted commands were run at the commit they name before the paragraph was written. The sweep is pinned to 9208ceb rather than to origin/main because this change is what moves its output. Refs #26 Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
…duce Two of the five pastes in the section that reads which contexts arrive had stopped reproducing. The branch-filter grep names three files and returns five; the type-filter grep names one line and returns two. Both moved for the same reason, which is that this board gained the release and smoke workflows since the reading was made, and neither of those runs on a pull request at all. The section already disclosed the commit it was read at, so nothing here was hidden. What was wrong is that the commands beside the pastes resolve origin/main, so a reader who ran one got an output the document did not carry and had no way to tell a workflow that narrows a pull request from one that runs on none. That is the failure this repair prevents: the section exists to find a context arriving on some pull requests and not on others, and a grep whose membership grows with every tag-triggered workflow buries that signal under files the question does not apply to. The new prose says which of the two a member is and what a reader should look for. Every paste was re-run before the sentence beside it was written, and the three that reproduce unchanged are named as such rather than left for a reader to re-derive. The means is prose in the document the issue names as the place for the result, and the readings stay commands a reader re-runs rather than a table, because a list of workflow files here would drift against the directory that decides it. Refs #62 Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
iderex
deleted the
parity/verdicts-for-five-declared-names-and-a-reading-that-stopped-reproducing
branch
August 29, 2026 17:50
This was referenced Aug 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two documents-only changes to
docs/quality-parity.md, on one branch and onepull request because both land prose in the same file and separate landings
would move the mainline under each other.
What I found, and how
#26: five declared check names had no verdict in the document
The done-condition of #26 assembles the required set from this document. A
comment on that issue recorded that every check name this tree declares carried
a verdict there, evidenced by a sweep whose only output was the six
buildentries. I re-ran that sweep at
9208ceb599a294328bde3d8b660c65a5fd3c5fb5before writing anything, and it prints ten:
The six
buildentries are the deliberate absence thebuildrow alreadycovers through
docs/decisions/0012-the-supported-platforms.md. The other fourare a gap. A fifth,
release, is a gap the sweep cannot show: the word matchesinside the reason on the SBOM row, and a fixed-string comparison cannot tell
that from a verdict.
All five read a tag or a published release, so they arrive on no pull request
and requiring one would hold every merge open for a tick that is not coming,
which is what
required-context-nothing-reportsrefuses. The paragraph I addeddrops them permanently rather than until #26, in the terms the table uses, and
says what dropping them from the gate does not drop: the smoke jobs are the only
thing here that reads what an operator downloads rather than the source it was
built from.
internal/contexts/contexts.goalready carries all five as absences, four ofthem under the shared
neverOnAPullRequestreason, so the tree and the documentnow agree instead of only the tree holding the answer.
#62: two of the five pastes in the trigger walk had stopped reproducing
The section that reads which contexts arrive discloses that its readings were
made at
1fc6961, and its commands resolveorigin/main. Two of them no longerreturn what is pasted beside them. Read at
9208ceb599a294328bde3d8b660c65a5fd3c5fb5:Three files where the document says three, and two type filters where it says
one. Both differences are the same cause: this board gained
release.ymlandsmoke.yml, and neither runs on a pull request.I re-ran the other three pastes in that section as well. The path-filter grep,
the branch grep over
dependency-review.ymland theif:count all reproduceunchanged, and the new prose names them as such rather than leaving a reader to
re-derive them.
The repair is more than fresh output. A grep for files carrying no
every-branch filter gains a member every time this board adds a tag-triggered or
release-triggered workflow, and those members answer nothing the section asks.
The new prose separates the two kinds of member and says the thing worth reading
for is a file that does run on a pull request appearing in the list.
What this does not do
Neither issue closes. #26 waits on the ruleset edit that adds the required set,
which is a repository setting rather than anything a change to this tree
reaches; #62 waits on that set existing to compare against, and on a pull
request opened from a fork. Both reasons are already written on those issues and
I have not repeated them there.
Nothing here measures a fork route, opens a licence file, or says what any job
found. The five names this change gives a verdict to are dropped from a required
set that does not exist yet, so the verdict is a statement about what may join
it rather than about anything holding a merge today.
The gate, run at the head of this branch
The timings are dropped from the suite output and nothing else is changed. The
run above was made with
-count=1and the-vrun that carries theintegration-hardware disclosure was made separately and passed; that harness was
not asked for and asking for it needs the hardware it names.
Means
Prose in the parity document rather than a new file or a new check. What was
missing in both halves is a verdict and a reading a person uses when assembling
a required set by hand,
internal/contextsalready holds the machine-readablehalf of the first, and a list of workflow files written into a document would
drift against the directory that decides it.
Reading
No second reader on this board tonight, so this body carries the evidence in
place of one: every command above was run before the sentence beside it was
written, and each paste names the commit it was read at.
Refs #26
Refs #62